Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-049.txt

Text File | 1992-11-18 | 42.4 KB | 1,165 lines | [TEXT/MPS ]

C.S.M.P. Digest             Mon, 13 Apr 92       Volume 1 : Issue 49

Today's Topics:

    calling XFCNs from an XFCN
    Smalltalk/V or C as ideal development tool?
    ASP, the Server Side
    Shift Key Woes
    Think-C Floating point support - Why so slow??
    OpenAda from Meridian, got any comment?
    THINK C 5.01 and QUADRA... )-:
    Oh no, more woes!
    Always having another rsrc file open (was Re: Preference Files/Folders: How to do under 6.x?)
    Mac Assembly Hacking
    Wanted: AppleTalk programming examples


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Clifford Harrison)
Subject: calling XFCNs from an XFCN
Date: 6 Mar 92 23:49:20 GMT
Organization: Martin Marietta

I am trying to call two XFCN's from an XFCN in Supercard.  The following works ocassionally:

#include "HyperXCmd.h"

pascal void
main(paramPtr)
XCmdBlockPtr    paramPtr;
{

    register     int i,len;
    typedef        void (*xfcn)();
    Handle        db_next_row,db_data,saveit;
    Str255        pattern,pattern2;
    xfcn        get_row,get_data;

    /* set up code pointers */
    db_next_row = GetResource('XFCN',1961);
    if(db_next_row == NULL)
        {
        return;
        }
    HLock(db_next_row);
    get_row = (xfcn)*db_next_row;

    db_data = GetResource('XFCN',1962);
    if(db_data == NULL)
        {
        return;
        }
    HLock(db_data);
    get_data = (xfcn)*db_data;

    HLock(paramPtr->params[2]);
    ZeroToPas(paramPtr, (unsigned char  *)*paramPtr->params[2], (StringPtr) &pattern);
    HUnlock(paramPtr->params[2]);

    while (1)
        {
        paramPtr->paramCount = 1;
        (*get_row)(paramPtr);
        HLock(paramPtr->returnValue);
        ZeroToPas(paramPtr,
            (unsigned char  *)*paramPtr->returnValue,
            (StringPtr) &pattern2);
        if (StringEqual(paramPtr, (unsigned char  *) &pattern,
                (unsigned char  *) &pattern2))
            {
            HUnlock(paramPtr->returnValue);
            paramPtr->returnValue = saveit;
            return;
            }
        else
            {
            HUnlock(paramPtr->returnValue);
            DisposHandle(paramPtr->returnValue);
            paramPtr->paramCount = 2;
            (*get_data)(paramPtr);
            HLock(paramPtr->returnValue);
            if (i==0)
                {
                saveit = paramPtr->returnValue;
                HandToHand(&saveit);
                }
            else
                HandAndHand(paramPtr->returnValue,saveit);
            HUnlock(paramPtr->returnValue);
            }
        }/* while(1) */
        return;

    }


By ocassionally i mean sometimes the return address of my XFCN or local variables get trashed.  Has anyone tried to do this before?

thanks.

My configuartion is:
Think C 5.0
System 7
Supercard 1.5
the two XFCN's are Sybase XFCN's

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Roger W. Brown)
Date: 11 Mar 92 13:55:15 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Clifford Harrison) writes:

> I am trying to call two XFCN's from an XFCN in Supercard.  The following works ocassionally:

I haven't done much with XCMDs in Supercard, so these ideas may not
apply.

Why not just use a callback?

resultHandle = EvalExpr(paramPtr,"\pGetRow()");

This does not work to well if you want to send long parameters to the
XFCN.

Also, it would be a bit slower than calling directly.


- -----------------------------------------------------------------
Roger Brown                           [e-mail]
Academic Computing
Dartmouth College, Hanover, NH

---------------------------

From: Brad Taplin <[e-mail]>
Subject: Smalltalk/V or C as ideal development tool?
Organization: Indiana University
Date: Mon, 9 Mar 1992 10:07:59 -0500

Hello,

I own Borland C++ and find it easy to work with, but the
language itself seems to some unnecessarily complex, and
tough to debug. I would like to hear from those who have
at least seen Smalltalk AND some affordable C like Think
or Borland C++ in action. My machine is a 386sx-16 sVGA.
Remember that gnu-ish Smalltalk and Smalltalk/V products
differ greatly. Roughly prioritized concerns include:

1. Speedy prototyping and incorporating the prototype into
   larger projects. Digitalk claims their Smalltalk makes
   this a breeze. I know there are code generators for C.

2. Reasonably doable debugging and tweaking. Smalltalk, I
   am told can be broken into small executable parts for
   testing more easily than can C++ classes or functions.

3. Tightness, reliability, and speed of final executables.
   C might take this prize, but who knows about Smalltalk?

4. Portability. Smalltalk code has been compiled without
   changes on various platforms. So has C. Don't include
   the "Hello" programs as we discuss Windows, OS/2, Mac.

5. Inherent advantages that might make either language a
   better tool for future GUIs like that of the PowerPC.
   Each is more than a language, more a complete system.

A textbook I recently skimmed in a local bookstore says
Smalltalk started with Kay's PhD at Utah in the sixties.
He foresaw Windows, mice, megabyte ram, and huge storage
on the desktop. Is Smalltalk inherently better for GUIs?

Thanks.

+++++++++++++++++++++++++++

From: [e-mail] (Cyberman)
Date: 10 Mar 92 01:29:02 GMT
Organization: The Tower of Zot - [phone]

[e-mail] (Brad Taplin) writes:
> 1. Speedy prototyping and incorporating the prototype into
>    larger projects. Digitalk claims their Smalltalk makes
>    this a breeze. I know there are code generators for C.
Well smalltalk from what little I've done is HARTYING at best.
I guess if you have the OOP nack it's not so bad.  But yes I must confess
this is true of small talk.
>
> 3. Tightness, reliability, and speed of final executables.
>    C might take this prize, but who knows about Smalltalk?
Small talk compiles OK but is large in size when independant from the
development package.
>
> 5. Inherent advantages that might make either language a
>    better tool for future GUIs like that of the PowerPC.
>    Each is more than a language, more a complete system.
Advantage of C++ is it's common availability.  Also you can run it on NON
GUI system unlike smalltalk.  Learning small talk is like getting braces.
It takes A LONG time before you get it straight.
Cyberman - NO JOKING.

A tagline a day keeps the vultures away.

+++++++++++++++++++++++++++

From: [e-mail] (John Unwin)
Date: 10 Mar 92 12:55:36 GMT

[e-mail] (Cyberman) writes:

>[e-mail] (Brad Taplin) writes:
>> 1. Speedy prototyping and incorporating the prototype into
>>    larger projects. Digitalk claims their Smalltalk makes
>>    this a breeze. I know there are code generators for C.
>Well smalltalk from what little I've done is HARTYING at best.
>I guess if you have the OOP nack it's not so bad.  But yes I must confess
>this is true of small talk.

Yes - but leaning to program MS Windows is no bowl of cherries!
so get the OOP nack  - in all events to use c++ properly you
should be using its OOP characteristics.

I use smalltalk/V for protypes and find it works very well, because
it can use DLLs you can work with a mixture of c :-( and Smalltalk :-)
The relative ease depends on whether you have classes that you can
use - or a similar application to adapt.

>> 3. Tightness, reliability, and speed of final executables.
>>    C might take this prize, but who knows about Smalltalk?
>Small talk compiles OK but is large in size when independant from the
>development package.

you need to ship the runtime DLLs + your application, although the
app is usually small the DLLs are about 900K (you may freely distribute)

You can use C for the processing intensive functions be writing the
c code, putting it a DLL then useing the DLL from smalltalk

Note that Smalltalk/V is quite resource hungry you will want somthing like
a 386 with 4Mb ram to work with any ease.

>>
>> 5. Inherent advantages that might make either language a
>>    better tool for future GUIs like that of the PowerPC.
>>    Each is more than a language, more a complete system.
>Advantage of C++ is it's common availability.  Also you can run it on NON
>GUI system unlike smalltalk.  Learning small talk is like getting braces.
>It takes A LONG time before you get it straight.
>Cyberman - NO JOKING.

You can use Digitalks smalltalk with minimal modification for the MAC and
OS/2 - for future GUIs you need to contact Digitalk, no doubt c++ will be
around for a while and would have the advantage of new class libraries
for new GUIs.

+++++++++++++++++++++++++++

From: [e-mail] (Markus Stumptner)
Date: 11 Mar 92 11:03:25 GMT
Organization: DB and ES Subdivision, TU Vienna

>From article <[e-mail]>, by [e-mail] (Cyberman):
> [e-mail] (Brad Taplin) writes:
>> 1. Speedy prototyping and incorporating the prototype into
>>    larger projects.
> Well smalltalk from what little I've done is HARTYING at best.

I'm sorry, but what does that word mean?

> I guess if you have the OOP nack it's not so bad.

If you don't want to use OOP, then Smalltalk indeed is not suitable.
In C++, one can always write code that looks just like C (judging from
your phrasing, is that your preference?  That's not what C++ is
about).

>> 5. Inherent advantages that might make either language a
>>    better tool for future GUIs like that of the PowerPC.
>>    Each is more than a language, more a complete system.
> Advantage of C++ is it's common availability.

There are Smalltalk implementations for X-Windows (for the major
workstation manufacturers), for MS Windows, for OS/2, for DOS and the
Mac.  Admittedly, you need graphics capability, but that's what the
question was about.

> Learning small talk is like getting braces.
> It takes A LONG time before you get it straight.

Especially when compared with a small, elegant and unrestricting
language like C++ :-) .
- --
Markus Stumptner                                [e-mail]
University of Technology Vienna                 vexpert![e-mail]
Paniglg. 16, A-1040 Vienna, Austria             ...mcsun!vexpert!mst

---------------------------

From: [e-mail] (Philip Brandenberger)
Subject: ASP, the Server Side
Organization: Swarthmore College
Date: Tue, 10 Mar 1992 10:39:45 GMT

Greetings,

I am using Appletalk to communicate between a client process on various
macs and a server application.  I would like to use ASP, but I find only
brief mention of the server side at all, and no clues as to what support
is available (what the protocol does for you, what calls to make, etc.)

Is the server side implemented, or is this done by each app through ATP?

If the server side is indeed part of .XPP, or some glue, where's it
documented?  I've checked IM I-VI, but not Inside Appletalk.

Replies via email please, as this is a dumb question.  :-)

Thanks,
Phil


- --
Philip J. Brandenberger
Swarthmore College, but I don't speak for it, usually against it.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Michael Peirce)
Date: 12 Mar 92 03:03:16 GMT
Organization: Peirce Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Philip Brandenberger) writes:
> Greetings,
>
> I am using Appletalk to communicate between a client process on various
> macs and a server application.  I would like to use ASP, but I find only
> brief mention of the server side at all, and no clues as to what support
> is available (what the protocol does for you, what calls to make, etc.)
>
> Is the server side implemented, or is this done by each app through ATP?
>
> If the server side is indeed part of .XPP, or some glue, where's it
> documented?  I've checked IM I-VI, but not Inside Appletalk.

ASP server side interfaces are not provided by Apple.  You have to
roll your own using ATP if you really have to use ASP.

Personally, I'd use ADSP.  It's got better throughput than ASP (since
ASP uses ATP and ADSP doesn't) and it fully supported.  Consider it.

- --  Michael Peirce         --   [e-mail]
- --  Peirce Software        --   Suite 301, 719 Hibiscus Place
- --  Macintosh Programming  --   San Jose, California USA 95117
- --           & Consulting  --   voice: [phone] fax: [phone]
- --                         --   AppleLink: peirce & America Online: AFC Peirce

---------------------------

From: [e-mail] (Joseph Peter Fleck)
Subject: Shift Key Woes
Organization: University of Illinois at Urbana
Date: Wed, 11 Mar 1992 05:42:04 GMT

Hello, all,
    Just a quick question.  Does anyone know the
C source for detecting a depression of the shift
key WITHOUT another key...  I know there's a way
to do it, I just can't figure it out.  ANY
ideas on the subject would be greatly appreciated.
E-mail is peachy.  Thanks.
- -Joe Fleck
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Armando Fox)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Wed, 11 Mar 1992 15:57:09 GMT

[e-mail] (Joseph Peter Fleck) writes:

>C source for detecting a depression of the shift
>key WITHOUT another key...  I know there's a way
>to do it, I just can't figure it out.

all foreground and most background applications receive regular
NullEvents.  check the modifiers field of a NullEvent's event record for
the shift key.

======================================================================
Armando Fox        Beckman Institute Vision/Robotics Group
[e-mail]        University of Illinois at Urbana-Champaign

"You're entitled to your own incorrect opinion."
======================================================================


+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 12 Mar 92 12:49:03 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Joseph Peter Fleck) writes:
>    Just a quick question.  Does anyone know the
>C source for detecting a depression of the shift
>key WITHOUT another key...  I know there's a way
>to do it, I just can't figure it out.  ANY
>ideas on the subject would be greatly appreciated.

All events come with the modifier flags set according to the conditions
that were present when the event was created. You can either get the
shit key state from your main event loop or you can ask for a null
event (with a 0 event mask) and find out the modifier keys from there.

Using GetKeys is another possibility, but I prefer getting the shift
key state from the event record, since I get events anyway and save a
trap call that way.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------

From: [e-mail] (Mike Smithwick)
Subject: Think-C Floating point support - Why so slow??
Organization: SF-Bay Public-Access Unix
Date: Wed, 11 Mar 1992 07:43:37 GMT

[]

Ok, I give up. What is the Think-C floating point library so damned
slow?? HUH?

I am porting a package over to the mac (Mac IIci) from my Amiga 3000. The
machines should be comparible in speed, but when compiled for software
floating point the Amiga using Moto. FFP libs runs rings around Think.
Trig functions are 10 times faster on the Amy, floating point divides
about 3 times faster. Heck, on the mac I tried a trig lookup table, and
it still runs 3 times slower than the Amiga FFP libraries.

I am using the "native" floating point mode, which seemed to have
sped things up just a tad over the "Universal" mode, but geeeze, isn't
there anything faster??



mike

P.S. Yes, I know about SANE, and FPUs and all that, but I want to
make this thing run fast on a Mac Classic.


- --
"There is no problem too big that can't be solved with high explosives"-Rush

Mike Smithwick - ames!zorch!mike


+++++++++++++++++++++++++++

From: [e-mail] (Doug McNaught)
Date: 11 Mar 92 19:05:48 GMT
Organization: California Institute of Technology

In article <[e-mail]> [e-mail] (Mike Smithwick) writes:
>[]
>
>Ok, I give up. What is the Think-C floating point library so damned
>slow?? HUH?

    It's slow because SANE is slow. SANE is slow because it's extremely robust
and accurate. Trig functions are done in software, even with an FPU present,
because the 6888[1,2] is not quite up to the SANE standard of accuracy.

>  [Amiga's Moto. FFP libs are faster than the Mac]

>I am using the "native" floating point mode, which seemed to have
>sped things up just a tad over the "Universal" mode, but geeeze, isn't
>there anything faster??

  Not without rolling your own.

>P.S. Yes, I know about SANE, and FPUs and all that, but I want to
>make this thing run fast on a Mac Classic.

  Sorry dude. If you really need it, you could always write your own set
of assembly language single-precision stuff. Fast fp on a Classic just isn't
doable otherwise. (I should know--that's all I can afford :-[ )

>--
>"There is no problem too big that can't be solved with high explosives"-Rush

  or handcrafted assembly code!

>
>Mike Smithwick - ames!zorch!mike


- --
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>
<> Doug McNaught                          [e-mail] <>
<>  Help!!! I'm addicted to *Spaceward Ho!* Is there a support group? <>
<><><><><><><><><><><><><><><>Go Skins!!<><><><><><><><><><><><><><><><>

---------------------------

From: [e-mail] (Peter Lau)
Subject: OpenAda from Meridian, got any comment?
Organization: State University of New York at Albany
Date: 11 Mar 92 11:36:19

Hi,

I would like to hear any comment (for example, how good is OpenAda?
How close with the std. Ada? Generic, Exception Handler? Concurrency?
Mac Toolbox support? Correct code generation?)

Will summarize if enough responds.

Thanks.

Peter Lau
- --
Peter Lau
- --

+++++++++++++++++++++++++++

From: [e-mail] (Chuck Shotton)
Date: 11 Mar 92 23:14:49 GMT
Organization: UTHSCH Academic Computing

In article <[e-mail]>, [e-mail] (Peter Lau) writes:
>
> Hi,
>
> I would like to hear any comment (for example, how good is OpenAda?
> How close with the std. Ada? Generic, Exception Handler? Concurrency?
> Mac Toolbox support? Correct code generation?)
>

I've used it. It does a good job of implementing Ada given the constraints of
the Mac's O/S. If you don't try to use every obscure Ada feature in the LRM,
it seems pretty stable. Compiler performance is something less than MPW
Pascal, but FAR better than it used to be. Tasking works as do generics.
However, there are limits placed on compilation unit size based on the Mac's
32K segment size. You have to be aware of just how huge things like generics
can turn out to be.

The MAJOR advantage to Meridian's Ada compiler is that you can buy it with the
Macintosh Environment Library, which provides packages for all of Inside Mac
volumes 1-5 (well, almost all). It also links well with MPW C (pragma import).

It is a validated compiler, so it obviously follows the standard quite
closely. It uses the same front end and development environment as all of
Meridian's other compilers, so if you're familiar with them, you can see what
the Mac version will be like.

Chuck

+++++++++++++++++++++++++++

From: [e-mail] (Paul Robichaux)
Date: 12 Mar 92 14:06:12 GMT
Organization: New Technology, Inc.

In <[e-mail]> [e-mail] (JohnC) writes:


>Since Apple's MPW C and Pascal compilers now have options to relax the 32K
>restriction, I wonder why Meridian hasn't followed suit?

There was a good bit of discussion on Meridian's OpenAda/Mac product
in comp.lang.ada a couple of months ago.

Consensus was that it was a pretty good first cut. However, according
to Meridian's sales manager for educational sales, sales volume of the
Mac version has been so low that Meridian doesn't plan to make any
major functional improvements: i.e. no Sys7 support, no relaxation of
the 32k restriction, and limited minor bug fixes. I presume that major
bugs (those which would prevent the compiler from passing the ACEC or
ACVC test suites) will still be fixed, sime they tend to come from the
backend rather than the common front-end.

- -Paul
- --
Paul Robichaux, KD4JZG          |  Read any good RFCs lately?
[e-mail]  |  Disclaimer: NTI pays for my skills.
                                |  My opinions are mine, not theirs or NASA's.
     Help port DEC Modula-3 to the Mac! Email for details.

---------------------------

From: [e-mail] (Miika Asunta)
Subject: THINK C 5.01 and QUADRA... )-:
Date: 11 Mar 92 15:38:39 GMT
Organization: Finnish Academic and Research Network Project - FUNET


I've been writing a program with THINK C 5.01 that I've found
very clean - ie. it works from MacPlus to fx with virtual memory on,
full colors etc.

It of course should have worked with Quadra... unfortunately, it didn't.
(with '040 cache on, without cache it worked perfectly).
It installed menus etc., but before giving control to the user
it bombed with ID 15, Segment Loader Error (GetResource('CODE',n) failed).

I wonder is it a problem of mine or problem or THINK compiler/linker.

I understand the 5.0.1 update should have fixed problems
with applications produced with THINK C.

>From "About 5.0 => 5.01" TeachText document:

    "When assigning one struct to another, the code THINK C
    generates now works correctly if the source struct is
    cached in an MC68040 data register."

That was the only comment on fixes for '040 besides the Source Debugger
fix. Are there other undocumented bugs? If so is there going to be
an update?

At the moment I have no chance to go a Quadra and run my software
with THINK C Source Debugger, which might clear to thins out.

Miika

- --
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&  Miika Asunta        &  [e-mail]  &  Double Bass Player   &
& tel. [phone]  &             &  Macintosh Programmer &
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

+++++++++++++++++++++++++++

From: [e-mail] (Scott Lindsey)
Date: 12 Mar 92 21:21:23 GMT
Organization: Claris Corporation

In article <[e-mail]>, [e-mail] (Miika Asunta) writes:
>
> It of course should have worked with Quadra... unfortunately, it didn't.
> (with '040 cache on, without cache it worked perfectly).
> It installed menus etc., but before giving control to the user
> it bombed with ID 15, Segment Loader Error (GetResource('CODE',n) failed).
>
> I wonder is it a problem of mine or problem or THINK compiler/linker.
>
I think it may be your problem.  Think C 5.0.1 (the actual compiler application) runs fine
on a Quadra 700 here, but if you want to use the debugger, you need to upgrade to 5.0.2.
The 5.0.2 release notes say they fixed problems with Quadras and the debugger.

- --
Scott Lindsey <[e-mail]>

---------------------------

From: [e-mail] (Joseph Peter Fleck)
Subject: Oh no, more woes!
Date: 12 Mar 92 03:56:28 GMT
Organization: University of Illinois at Urbana

Ok, this is similar to my last post, but slightly different.
The question is, say you were laying your finger on
the "8" key, and wanted to keep that "autoKey" in the
Event.what field active when you hit the Shift key.  This
is what I want.  I would like (for a game that is nearing
completion) to be able to keep a tank moving with the
keyboard whilst firing with the shift key.  What happens,
is that when the shift key is hit, the autoKey gets set
back to a keydown event.  I've even tried to get around
this by checking to see if the shift key was hit and
the same previous key is being still held down... No
dice... How would you do it, o programmers of the
net?  Thanks again!

- -Joe Fleck
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Ernest J Hill)
Date: 12 Mar 92 14:55:25 GMT
Organization: Massachusetts Institute of Technology

If you need to keep track of the status of multiple keys at once, you can't
really use key events; you should instead use the toolbox routine GetKeys(),
which gives you back a 'KeyMap' structure.  The KeyMap contains the status
of *every* key (I think this is true unless more than 5 keys are down at
once).  Anyway, this is in IM I, I don't have mine here so no page reference,
sorry.  Good luck!  I hope this helps.
                    --Foss Hill

+++++++++++++++++++++++++++

From: [e-mail] (Chuck McMath)
Date: 12 Mar 92 13:18:16 GMT
Organization: MSD

In article <[e-mail]>, [e-mail] (Joseph Peter Fleck) writes:
>
> Ok, this is similar to my last post, but slightly different.
> The question is, say you were laying your finger on
> the "8" key, and wanted to keep that "autoKey" in the
> Event.what field active when you hit the Shift key.  This
> is what I want.  I would like (for a game that is nearing
> completion) to be able to keep a tank moving with the
> keyboard whilst firing with the shift key.  What happens,
> is that when the shift key is hit, the autoKey gets set
> back to a keydown event.  I've even tried to get around
> this by checking to see if the shift key was hit and
> the same previous key is being still held down... No
> dice... How would you do it, o programmers of the
> net?  Thanks again!
>
> -Joe Fleck
> [e-mail]
>
>

My suggestion would be to use GetKeys to retrieve the keyboard state.  In
that way you can check to see which keys are being held down at any time.
The only problem with this is that you can't rely on events and have to
be in a tight polling loop.  But for a game that isn't too much of a
restriction.

chuck

                       --chuck mcmath-
                    [e-mail]
  MSD, Inc. * National Library of Medicine * National Institutes of Health
                       Bethesda, MD 20894

---------------------------

From: [e-mail] (Jamie R. McCarthy)
Subject: Always having another rsrc file open (was Re: Preference Files/Folders: How to do under 6.x?)
Organization: Kalamazoo College
Date: Thu, 27 Feb 1992 21:25:44 GMT

[e-mail] (Steve Dorner) writes:
>Eudora keeps her settings file open all the time.  Settings are kept
>in a resource, and having the settings file open means it's always at
>the top of the resource chain.  This has the benefit of allowing users
>to override resources in Eudora by putting resources in the settings
>file.
>
>What's nice about putting these resources in the settings file is that
>a) they don't affect other users, like they would if users editted the
>app directly and b) users don't lose their customizations when they upgrade
>to the next version of Eudora.

I agree, that's a nice setup.

I remember reading an article in csmp a few weeks ago that indicated
that the Help Manager would only search the first file in the resource
chain.  I took this to mean that I should always have the topmost
resource file be the application file, at least every time I went
through WaitNextEvent.  Not only for balloon help, but also because
Apple has apparently decided to require this...

Any comments, anyone?
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.



- -------------------------

From: [e-mail] (Steve Dorner)
Date: 3 Mar 92 19:29:55 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] (Jamie R. McCarthy) writes:
>I remember reading an article in csmp a few weeks ago that indicated
>that the Help Manager would only search the first file in the resource
>chain.

Not currently.  If it were so, Balloon Help wouldn't work in Eudora.

>I took this to mean that I should always have the topmost
>resource file be the application file, at least every time I went
>through WaitNextEvent. ... Apple has apparently decided to require this

Do you have some documentation on this requirement?
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

- -------------------------

From: [e-mail]
Date: 28 Feb 92 18:29:41 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>[e-mail] (Steve Dorner) writes:
>>What's nice about putting these resources in the settings file is that
>>a) they don't affect other users, like they would if users editted the
>>app directly and b) users don't lose their customizations when they upgrade
>>to the next version of Eudora.
>
>I agree, that's a nice setup.
>
>I remember reading an article in csmp a few weeks ago that indicated
>that the Help Manager would only search the first file in the resource
>chain.  I took this to mean that I should always have the topmost
>resource file be the application file, at least every time I went
>through WaitNextEvent.  Not only for balloon help, but also because
>Apple has apparently decided to require this...
>
    I believe that I was the one that wrote the thingy about the Help
Mngr using Get1Resource calls, so I'll comment ;-)

    It is not the entire HelpMgr that is stupid enough to use Get1 calls,
jnust some of it - ufnortunately it is not documented which do and which
do not.  I discoverd the problem the hard way in that MPII also keeps a whole
slew of other resource forks open (prefs, toolbox, settings, etc.) and my
"Dynamic Window Help" code wasn't working.  Menus (hmnu's) worked fine
and hdlg's worked fine, but when calling HMShowBalloon yourself it just
couldn't get it right...A little trip into the debugger showed what was
going on.

    I don't see any reason that switching CurResFile (via UseResFile)
in yoru event loop & only changing it when you need ot wouldn't work -
unless you've got executing code in some of those forks (for example
XCMD's).


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Date: 6 Mar 92 20:07:16 GMT
Organization: University of Illinois at Urbana-Champaign

[e-mail] writes:
>"Dynamic Window Help" code wasn't working.  Menus (hmnu's) worked fine
>and hdlg's worked fine, but when calling HMShowBalloon yourself it just
>couldn't get it right

HMShowBalloon has always worked fine for me in Eudora, and I always keep the
preferences file, not the application, at the top of the resource chain.

Was this perhaps a bug in beta versions of System 7?  Or are only certain
help resource types affected?  I'm using khmmStringRes's, and they work
fine.
- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail]
Date: 8 Mar 92 20:18:52 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>I remember reading an article in csmp a few weeks ago that indicated
>>that the Help Manager would only search the first file in the resource
>>chain.
>
>Not currently.  If it were so, Balloon Help wouldn't work in Eudora.
>
    If you don't make any direct calls to the Help Manager that bring up
Balloons you are OK - but some/all of the "direct" calls like HMShowBalloon,
HMShowMenuBalloon, HMExtractHelpMsg only use a Get1Resource...

- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail]
Date: 8 Mar 92 20:26:13 GMT
Organization: Campus Computing Sites, University of Michigan-Ann Arbor

In article <[e-mail]> [e-mail] (Steve Dorner) writes:
>[e-mail] writes:
>>"Dynamic Window Help" code wasn't working.  Menus (hmnu's) worked fine
>>and hdlg's worked fine, but when calling HMShowBalloon yourself it just
>>couldn't get it right
>
>HMShowBalloon has always worked fine for me in Eudora, and I always keep the
>preferences file, not the application, at the top of the resource chain.
>
    The problem, after going back and looking at my notes, was not in
the HMShowBalloon call, but in the HMExtractHelpMsg routine which I use to
get WHATEVER type of helpis available since this code is used both for
"internal" and "external" dialogs so there may be PICT or TEXT/styl based
help so I need to get the "correct" info.


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

+++++++++++++++++++++++++++

From: [e-mail] (Ross Brown)
Date: 10 Mar 92 15:45:36 GMT
Organization: Bell-Northern Research

In article <[e-mail]>
[e-mail] writes:
>In article <[e-mail]> [e-mail]
(Steve Dorner) writes:
>>[e-mail] (Jamie R. McCarthy) writes:
>>>I remember reading an article in csmp a few weeks ago that indicated
>>>that the Help Manager would only search the first file in the resource
>>>chain.
>>
>>Not currently.  If it were so, Balloon Help wouldn't work in Eudora.
>>
>    If you don't make any direct calls to the Help Manager that bring up
>Balloons you are OK - but some/all of the "direct" calls like HMShowBalloon,
>HMShowMenuBalloon, HMExtractHelpMsg only use a Get1Resource...
>

I may be the author of the posting that Jamie refers to.  I have had several
discussions with the author of the Help Manager.  My specific complaint was
that 'hovr' resources were not respected if not found in the current resource
file, so putting them in the application file is not sufficient if you always
keep the preferences file open.  As you say, this is because Get1Resource is
being called.

If HMShowBalloon gives you trouble because the help message record refers to a
resource not in the current resource file, you can always use CurResFile to
twist things the way you want.  It's the cases you DON'T have direct program
control over, like 'hovr', that are annoying.

Ross Brown
Bell-Northern Research Ltd.
Ottawa, Ontario, Canada
[e-mail]
Opinions expressed do not necessarily represent those of BNR.

---------------------------

From: [e-mail] (James R. Osborn)
Subject: Mac Assembly Hacking
Date: 29 Feb 92 06:24:42 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley


Hi folks,

I got a friend, see?  He want's to disassemble
some Mac code resources to see exactly what they're
doing.  Then he'd like to be able to hack on the
code to customize it, (i.e. "FIX" it).  I've heard
of some tools that let you do this kind of stuff,
but I've not done anything of the kind myself.

What are the best tools to do this kind of work?
All opinions are welcome regarding shareware and/or
comercial products.  Please e-mail responses to me,
and I shall summarize.

-- James

 ------------------------------ ))) -------------------------------------------
            James R. Osborn    (((   It just goes to show you it's always
 Lawrence Berkeley Laboratory   \\\    something.  Either it's goofy
            [e-mail]   )))    tech notes or your mac is flying!
              [phone]    (((   It's always something...
 ------------------------------- \\\ ------------------------------------------



+++++++++++++++++++++++++++

From: [e-mail] (James R. Osborn)
Date: 9 Mar 92 03:00:35 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley

Regarding tools for disassembling and hacking on Mac
code resources and such, I'd like to thank these folks
for replying:

[e-mail]            (Dameon D. Welch)
[e-mail]   (Todd Green)
[e-mail] (Josh)
[e-mail]             (Scott E. Lasley)
[e-mail]      (Peter Creath)
[e-mail]                (Andre "Just A Plumber" Srinivasan)
[e-mail]                    (Steve P Day)

Most suggestions were for ResEdit with the combination CODE
disassembler/editor.  You can edit the resource using a HEX
editor and then see if it disassembles the way you want it
with the disassembler.  The disassebler does a nice job of
letting you navigate the resource by providing double-clickable
(graphically displayed) links where the code branches or jumps
to a subroutine.

The next most popular suggestion was for MacsBug, the Macintosh
debugger, which disassembles anything in memory.  You can use
"set memory" commands to edit code in memory on the fly.  I
guess you could load a resource in memory, hack on it with
MacsBug, and then (after setting resChanged attribute) write
the resource out to a file.  The MacsBug interface is much
more bare-bones than the ResEdit CODE disassembler, but it
obviously has a lot of other features for debugging.

ResEdit, the optional CODE editor/disassembler (which you
install into ResEdit or its preferences file), and MacsBug
are all available from Apple via anonymous ftp at the host
"ftp.apple.com".  Look in the /dts/mac/tools/resedit and
/dts/mac/tools/macsbug directories.

One other suggestion was for the MPW DumpCode tool which will
dissassemble code resources.  This presumably comes with MPW,
but since I don't have it, I don't know for sure.  No comments
on ways to edit with this tool.

Thanks folks.  Actually I was hoping for something a little
more friendly than HEX editing and set mem'ing.  If anyone
has anything to add to this scant list of tools, feel free.

- -- James

 ------------------------------ ))) -------------------------------------------
            James R. Osborn    (((   It just goes to show you it's always
 Lawrence Berkeley Laboratory   \\\    something.  Either it's goofy
            [e-mail]   )))    tech notes or your mac is meditating!
              [phone]    (((   It's always something...
 ------------------------------- \\\ ------------------------------------------

+++++++++++++++++++++++++++

From: [e-mail] (Francois Menneteau)
Date: 12 Mar 92 10:42:28 GMT
Organization: IMAG Institute, University of Grenoble, France

In article <[e-mail]> [e-mail] writes:
>Regarding tools for disassembling and hacking on Mac
>code resources and such, I'd like to thank these folks
>for replying:
>Thanks folks.  Actually I was hoping for something a little
>more friendly than HEX editing and set mem'ing.  If anyone
>has anything to add to this scant list of tools, feel free.
>

I wrote an application called RSC_Viewer that lets you dump,
disassemble and modify any kind of resources.

There is a DEMO version at sumex, but in this version
the patch functionnality is disabled. Otherwise the
application is shareware.

The disassembler recognizes traps (even dispatch ones), symbols
if they are available, low memory global variables, etc (see
other features in the documentation).

You can of course modify the resources, and when the resources are
of executable types (eg CODE, XCMD, etc) you can use the built-in
ASSEMBLER instead of the dump mode.

You can also search for a specific trap or value in the resources.

The current version is 6.3 (full system 7 compatible with required
AppleEvents support and of course free bug :-)) [it is v6.2.2 at
Sumex (if I remember well)].


- --
Francois Menneteau ()   __|||||__   () "... I had their lives in my hands
================== ()    /O   O\    () their fate their fortune in my visions
[e-mail]       ()    - .|. -    () No one believed in my true prophecy
================== ()     \=^=/     () And now it's too late."  (Iron Maiden)

---------------------------

From: [e-mail] (Steve Ko)
Subject: Wanted: AppleTalk programming examples
Date: 1 Mar 92 11:11:34 GMT
Organization: Massachusetts Institute of Technology

Does anyone know where I can find some AppleTalk programming examples?
I'm writing a network game and am having trouble deciphering from IM
the "preferred" way of calling the AppleTalk routines.  In particular,
I'd like to see examples using NBP and ATP.  If anyone has suggestions
of useful texts (other than IM2,IM5,Inside AppleTalk) on this subject,
I'd greatly appreciate it if you could send me info about them.

You can e-mail me at [e-mail] or simply post your reply to
the net.

Thanks very much for your help!

                    - Steve Ko



+++++++++++++++++++++++++++

Organization: Queen's University at Kingston
Date: Tuesday, 10 Mar 1992 23:01:36 EST
From: <[e-mail]>

  If you want to _use_ AppleTalk I'd suggest you skip Inside AppleTalk (it's
interesting, and detailed, but definitely not a "how to" book).  I do recommend
Michael Peirce's book "Programming with AppleTalk" (Addison-Wesley, $25 U.S.,
ISBN 0-201-57780-1).  I found it very readable.  Unlike other books in the
series, however, it is not available in a version bundled with a source code
disk.

.../dave    Dave Charlesworth

---------------------------

End of C.S.M.P. Digest
**********************